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1. INTRODUCTION 


1.1 Identification of Document 

This document describes the baseline requirements for the Moderate-Resolution Imaging 
Spectroradiometer (MODIS) Level 1A software, to be produced by the MODIS Science Data 
Support Team (SDST) for the MODIS Science Team. The MODIS SDST objectives include the 
support of the MODIS Science Team Leader and Team Members in developing, implementing, 
integrating, testing and documenting MODIS data processing software, and thereby helping to 
meet the scientific goals of the Earth Observing System (EOS) effort. Specific to this effort, the 
SDST is responsible for the development of the Level 1A software. 

1.2 Scope of Document 

This document provides a complete description of the functional, operational, and data 
requirements for the MODIS Level 1 A software. Specifically, it defines the internal requirements 
in terms of the data and process functional requirements of the software as well as the 
performance and quality engineering, safety, and security requirements. In addition, it provides 
the external interface requirements imposed on the MODIS Level 1A process by the Data 
Archive and Distribution System (DADS); Scheduling, Control, Monitoring, and Accounting 
(SCMA); Product Management (PM) System; and MODIS Log as well as the assumptions made 
in the MODIS Level 1A software on the Product Generation System (PGS). This document also 
provides the implementation constraints and requirements for adapting the software to the 
physical environment (site adaptation). An overview of the phased development of the software 
is also provided^. 

1.3 Purpose and Objectives of Document 

The purpose of this document is to specify the functional, performance, and interface 
requirements of the MODIS Level 1A software. It has been developed to provide the basis for 
the MODIS Level 1A Systems Requirements Review (SRR) and the establishment of the 
functional baseline for the software. 

1.4 Document Status and Schedule 

This document, when approved, contains the official MODIS Level 1A requirements which form 
the basis for the design of the Level 1A software. The requirements will be updated as 
necessary, under configuration control, and updates of the document will be released as 
produced. 

1.5 Documentation Organization 

This document has been tailored using NASA-STD-2100-91 and NASA-DID-P200. It has been 
organized into the following sections. All related documentation including the MODIS 
programmatic documents as well as the applicable standards and guidelines are provided in 
Section 2. Section 3 provides the requirements approach. Section 4 describes the external 
interface requirements and Section 5 the internal requirements. Section 6 provides traceability 
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to parent’s design. Section 7 describes the phased delivery approach to be used for the MODIS 
Level 1A software. Section 8 contains a list of acronyms for this document. Section 9 is a 
summary of the glossary of terms. Appendix A details the MODIS Level 1A structured 
specification. Appendix B contains the MODIS Level 1 development schedule, while Appendix 
C provides an estimate of the MODIS Level 0 and Level 1A data rates and volumes and the 
proposed data structures. 

1.6 MODIS Overview 

The overall MODIS objective is to make long-term observations for improved understanding of 
the global dynamics and processes occurring on the land surface, ocean surface layer, and lower 
atmosphere (including surface-atmosphere interactions) by exploiting the visible, near-infrared 
(IR), and thermal-IR spectrum with observation resolutions of 1 to 2 days and 250 m to 1 km. 

The MODIS measurement objectives include surface temperature (land and ocean), ocean color 
(sediment, phytoplankton), global vegetation maps, global change (deforestation and 
desertification), cloud characteristics, aerosol concentrations and properties, atmospheric 
temperature and moisture structure, snow and ice cover characteristics, and ocean currents. 
Additional measurement objectives include chlorophyll concentration, primary productivity, 
sediment transport, standing water, wetland extent, vegetation properties, hemispherical albedo, 
bidirectional reflectance, cloud properties, and aerosol radiances. 

MODIS will observe nearly the whole Earth twice a day for at least 15 years in two series of 
three spacecraft each. These spacecraft will be flown in 705-km circular, sun-synchronous orbits 
with 10:30 AM descending node and 1:30 PM ascending node equator crossings. The first 
launch will take place in June 1998. MODIS data products, beginning at Level 1A, are required 
by the members of the MODIS science team and members of the other EOS facility instrument 
teams, the EOS interdisciplinary investigators, and the scientific community at large. The 
primary data systems include the MODIS instrument and its processor (from sensor signals to 
data packets), the EOS platform and the Tracking and Data Relay Satellite System (TDRSS) 
(data transmission from the instrument through the platform and TDRS, to the ground), and the 
ground processing system including the EOS Data and Information system (EOSDIS). A set of 
definitions defining the processing stages for instrument data from sensor signal through data 
product are given in Table 1. 

The land objective is to collect data for studies of the spatial and temporal variability in land 
surface properties (e.g., surface temperature, primary production, evapotranspiration, and 
photosynthesis, vegetation cover and phenology, snow and ice, radiative properties including 
radiation balance) with emphasis on problems such as desertification, regional vegetation stress 
due to acid rain or drought, and succession or change in vegetation species due to deforestation 
and anthropogenic effects. 

The ocean objective is to collect data for studies of the spatial and temporal variability of ocean 
surface thermal and bio-optical properties (e.g., water-leaving radiances, photosynthetic 
pigments, sea surface temperature, flow visualization, attenuation coefficients and sea ice) with 
special emphasis on ocean primary productivity. 
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Table 1. Data Definitions 

Data Level 

Data Definition 

Level 0 

Instrument-Data at original resolution, time order restored, with duplicates removed. 

Level 1A 

Level 0 data which are reformatted, with Earth location, calibration data, and other 
ancillary data included. 

Level IB 

Level 1A data to which the radiometric calibration algorithms have been applied to 
produce radiances or irradiances. 

Level 2 

Geophysical parameter data retrieved from the Level IB data by application of 
geophysical parameter algorithms. 

Level 3 

Earth-gridded geophysical parameter data, which have been averaged, gridded, or 
otherwise rectified or composited in time and space. 

Level 4 

Analyses of the lower levels of instrument data, generally involving detailed model 
calculations. 


The atmosphere objective is to collect data for studies of tropospheric dynamics, climatology, 
and chemistry as obtained through observations of cloud characteristics (height, type, albedo, 
optical depth, effective droplet radius, and thermodynamic phase), aerosol properties, water 
vapor, and temperature. 

1.7 Level 1A Software Description 

MODIS Level 1A software accepts as input MODIS instrument packets that have been 
time-ordered, error-corrected, and with duplicates removed, during earlier Level 0 processing. 
The data is unpacked into full words and placed into standard Hierarchical Data Format (HDF) 
structures. The Earth location of each spatial element will be computed and included with the 
science data. Metadata and other descriptive header/ summary, information is generated to 
describe the product, which is archived at the Goddard Space Flight Center (GSFC) Distributed 
Active Archive Center (DAAC). The Level 1A product is the primary EOS archive of MODIS 
instrument data, and the entry point for all higher-level standard product generation. By 
definition and design, Level 1A data is fully reversible to Level 0 data, guaranteeing the ability 
for the removal of all processing artifacts in the event of future reprocessing cycles. The Level 
1A software is designed to process MODIS instrument data in all operating modes, including 
during ground calibration and at spacecraft integration, as well as for quick-look processing for 
three concurrent MODIS spacecraft. 

2. RELATED DOCUMENTATION 

2.1 Parent Documents 

• NONE 
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2.2 Applicable Documents 

• NASA-STD-2100-91, NASA Software Documentation Standard, Software 
Engineering Program, dated July 29, 1991 

• NASA-DID-P200, Requirements 

• SEL-81-305, Recommended Approach to Software Development, Revision 3, dated 
June 1992 

• EOS Science Software Developer’s Handbook 

• Structured Analysis and System Specification, Tom Demarco, Yourdon Press, 1979. 

• Strategies for Real-Time System Specification, Derek J. Hatley and Imtiaz Pirbhai, 
Dorset House, 1987 

2.3 Information Documents 

Information in the following documents is not binding. 

• DoD-STD-2167A, Defense System Software Development, dated 29 February 1988 

• MIL-STD-1521B, Technical Reviews and Audits for Systems, Equipments, and 
Computer Software, dated 1 June 1985 

• MODIS Level 1A Data Processing System, Revision 1, MODIS Data Study Team, 
dated April 12, 1991 

• MODIS Software and Data Management Plan (draft), dated August 28, 1992 

• MODIS Science Computing Facilities (SCF) Plan (draft), dated October 20, 1992 

• MODIS Science Data Support Team (SDST) Coding Recommendations for the 
MODIS Science Team (draft), dated April 10, 1992 

2.4 Other Related Documents 

• MODIS-HIRIS Ground Data Systems Commonality Report, NASA Technical 
Memorandum 100718, dated December 1988 

• MODIS Information, Data, and Control System (MIDACS) Level II Functional 
Requirements, NASA Technical Memorandum 100718, dated December 1988. 

• MODIS Information, Data, and Control System (MIDACS) Operations Concepts, 
NASA Technical Memorandum 100720, dated December 1988. 
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• MODIS Information, Data, and Control System (MIDACS) System Specifications 
and Conceptual Design, NASA Technical Memorandum 100721, dated December 
1988. 

3. REQUIREMENTS APPROACH 

The SDST has performed an analysis of the MODIS Level 1A requirements. The requirements 
are formulated to be quantifiable and testable. Our requirements analysis approach, described 
below, consists of two key processes: 

• Requirements Analysis and Synthesis Process 

• Requirements Change Control Process 

The change control process is described in the MODIS Software Configuration Plan (to be 
published). 

3.1 Requirements Analysis and Synthesis Process 

Figure 3-1 illustrates the process used to analyze and synthesize the MODIS Level 1A 
requirements. The following steps were taken to produce this document: 

• Gathering of Information 

• Interviewing of System Users 

• Development of Requirements List 

• Development of Requirements Analysis Model 

• Iteration of the Process 

3.1.1 Requirements Synthesis 

The MODIS requirements for science software are given in the MODIS Team Leader Statement 
of Work, Execution/Operations Phase. 

Over an extended period of time, the SDST gathered information about the MODIS Level 1A 
processing and the requirements for the datasets. The SDST interviewed the users of the Level 
1A datasets and synthesized these inputs into a list of requirements and design assumptions. 
Later, the SDST distilled the list of requirements and design assumptions into a list of prime 
requirements (see sections 4 and 5). The SDST then used the prime requirements as a basis for 
analysis using a model. The SDST is using structured analysis with real-time extensions as the 
primary methodology for analyzing the MODIS Level 1A requirements. 

3.1.2 Structured Analysis 

The SDST has chosen the structured analysis methodology developed by Tom DeMarco, as 
described in, "Structured Analysis and System Specification", Tom Demarco, Yourdon Press, 
1979, along with the real-time extensions defined by Ward and Mellor. The output of the 
structured analysis process is a structured specification. The structured specification (see 
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Figure 3-1 . The SDST's Iterative Requirements Document Development Process Ensures That User Requirements are 
Fully Incorporated. 











Appendix A, MODIS Level 1A Structured Specification) is graphical and hierarchical in nature. 
The specification represents different layers of abstraction with the top layer illustrated by the 
context diagram. This specification consists of an integrated set of data flows, data dictionary 
definitions, control flows, and transform descriptions that model the MODIS Level 1A 
processing. (Control flows are not generally included in data flow diagrams, but they are 
included here for convenience, consistent with Ward and Mellor’s real-time extensions.) This 
model is a top-down partitioned representation of the logical functions of the system, and is 
easily modified and maintained. The graphic nature of the model lends itself nicely to analysis 
of the overall design and to identification of problems and inconsistencies in the baseline 
requirements. The top-level model of the system is the Layer 0 Data Flow Diagram (DFD). 1 

A DFD identifies functions and the data that must flow between the functions (the interfaces). 
Other elements that may be identified are data stores (usually files), and external entities in the 
form of sources and sinks. These sources and sinks represent elements, persons, or 
organizations that lie outside the context of the system, but which originate or receive data flows 
that are part of the system. Processes are represented by numbered circles (or bubbles) and 
denote the transformation of incoming data into outgoing data. Data flows are represented as 
labelled arrows between the other elements. Further data flows are decomposed into smaller 
elements on lower-level DFDs. Data flows, data stores, processes, and anything else that needs 
defining are defined in the Data Dictionary. 

As indicated previously, the top-layer processes must be decomposed to provide more detail. 
Each process is analyzed and described with a more detailed DFD. Each lower-layer DFD more 
completely describes an entire process contained in a higher-layer diagram. Sources and sinks 
are, traditionally, not shown on these lower-layer diagrams. These layer 1 DFDs are further 
decomposed into lower-layer DFDs until the desired level of detail is attained in the diagram. 
The processes identified at the most detailed layer are then described, using one of a number of 
specification techniques, in a Process Specification Data Dictionary entry. These processes are 
the functional primitives and form the basis for the requirements traceability which is carried 
throughout the development life cycle. 

As noted earlier, the data flows represent pipelines through which data packets of definite 
composition flow. The composition of the data packets and of the data stores are described in 
the Data Dictionary. Each entry in the dictionary defines the structure of a data element in the 
DFD, including its decomposition, using a structured language adapted from the Bacus-Nauer 
form, into data element primatives. All elements that appear at any layer of the DFD must 
appear in the dictionary to assure that the model is rigorous. Some elements are built from other 
elements using the logical constructs of sequence, selection and iteration. Each element used to 
build another data element must also be defined. 


'The top-level DFD is normally called the "Level 0 DFD." Because of the use of the word “Level" to refer to data 
products, all DFD ’’levels" are here referred to as "layers.” 
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Where applicable, control flows are used in the DFDs to represent control information flowing 
through the system. In the MODIS Level 1A processing, the primary control flows originate in 
the PGS Scheduling and Execution Subsystem. 

3,1.3 CASE Tool Usage 

The SDST is using CADRE’S Teamwork suite of Computer Aided Software Engineering (CASE) 
tools to support the requirements analysis process. The products attached in Appendix A were 
generated directly from the Teamwork SA/RT, Structured Analysis with Real Time extensions. 
Teamwork automates the generation of the structured specification and supports Tom Demarco’s 
methodology using a variety of DFD checks. 

In addition to the structured analysis tools, the SDST is using CADRE’S Rqt, requirements 
traceability tool. Rqt supports the allocation of prime and derived requirements to processes 
represented using Teamwork SA. 

3.2 Requirements Change Control Process 

Figure 3-2 illustrates the Requirements Change Control Process that the SDST will use to control 
the MODIS Level 1A requirements. 

3.2.1 Software Requirements Review 

A Software Requirements Review (SRR) was held on May 11, 1993 to provide the user 
community the opportunity to comment in an open forum on the requirements analysis results. 
The SDST incorporated the comments from the SRR attendees into this Baseline Requirements 
document for approval by the MODIS SDST Configuration Control Board (CCB) as the 
requirements baseline for MODIS Level 1A software. 

3.2.2 Change Control Process 

The MODIS software change control process is documented in the MODIS SDST Configuration 
Management Plan (to be published). The MODIS SDST CCB is co-chaired by Ed Masuoka and 
A1 Fleig. Representatives from the EOS Project, the MODIS Science Team, and the MODIS 
Characterization Support Team (MCST) are invited to become members of the CCB. The CCB 
meets whenever a Configuration Change Request (CCR) is made by a user or developer of the 
system. 

4. EXTERNAL INTERFACE REQUIREMENTS 

4.1 Requirements Imposed on the MODIS Level 1A Process 

The MODIS Level 1A process interacts with the EOSDIS system in both a functional and 
physical manner. Functionally, the Level 1A process receives Level 0 Data and supporting 
ancillary datasets from the DADS, performs control and status interactions with the PGS, writes 
processing status to the MODIS processing log, and produces the Level 1A output data products. 
All of these functions are to be accomplished physically via the EOSDIS Core System (ECS) 
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PGS Tool Kit function calls. This is an implementation constraint on the design of the system, 
the details of which are not known at the present time. 

The attached MODIS Context diagram (see Appendix A) illustrates the relationship of the 
MODIS data processing with the external entities to the MODIS processes. For the purposes 
of completeness, we have chosen to include the context diagram of the entire MODIS data 
processing software. The Level 1A context is shown in the layer 0 DFD. The external entities 
are the functions that are not a part of the MODIS software effort. The requirement items in 
this section are categorized by the external entities to the MODIS Level 1A process as shown 
in the Context Diagram and are limited to the functionality of the design. Implementation 
techniques and requirements are not included in this document but will be included in the 
Interface Control Document. 

4.1.1 Data Archive and Distribution System 

The DADS is the storage area for all input and output data products ingested or produced by the 
MODIS Level 1A process. The DADS is the local segment at each site in the web of DAACs. 
It is the DADS responsibility to stage the required input data locally. A minimal set of the 
ancillary data required for the Level 1A process will be contained within the Level 0 Data 
Product. This includes the spacecraft platform position and attitude data. Additional ancillary 
data, such as improved sensor geometric correction parameters, refined platform orbit and 
attitude, and digital terrain elevation data will be used, when available, to improve accuracy of 
the generated Earth location data. These additional ancillary datasets, archived by the DADS and 
accessed via the PGS Tool Kit, will be staged to the MODIS Level 1A processor prior to 
process execution. The MODIS Level 1A process will not specifically request the DADS to 
stage Level 0 data, these data having been obtained before Level 1A processing begins. 

• IF01 : MODIS Level 1A Input Data. The MODIS Level 1A process shall ingest the 
MODIS Level 0 instrument data packets containing all instrument generated data with 
embedded spacecraft position and attitude, and a data transmission accounting packet 
generated bv the EOS Data and Operations System (EPOS) . All MODIS instrument 
data are contained within the Level 0 data packets. The Level 1A process will 
assemble these packets into an organized computer data structure (scan cube) as 
described in section 5 of this document and further detailed in Appendix C— MODIS 
Data Rate and Volumes with the proposed Computerized Data Structure, latest 
edition. The accounting data produced by the EDOS will be included as part of the 
Level 0 Data Product and will contain the origination and quality indicators derived 
by EDOS during the reconstruction of the instrument packets from the TDRSS 
transfer packets. Data exchange and handshaking will be between the MODIS Level 
1A process and the PGS tool kit. The DADS will perform all data staging. 

• IF02: MODIS Level 1A Ancillary Input Data. The MODIS Level 1A process shall 
read the ancillary input data required to generate standard Level 1A products . The 
DADS will archive the ancillary datasets needed to produce standard products, such 
as sensor geometric correction parameters, refined platform orbit and attitude data, 
Digital Elevation Model (DEM) data, and Earth geoid data. Access to these ancillary 
datasets will be provided by the PGS Tool Kit. Copies of ancillary datasets which do 
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not change or change only infrequently (e.g., DEM and geoid data) may, for 
performance reasons, be maintained locally by the PGS Level 1A processing system 
to limit the data staging requirements for each product. Updates to these local 
ancillary datasets would occur only as changes were made to the master data in the 
DADS. 

• IF03. MODIS Geometric Distortion Data. The MODIS Level 1A process shall 
output measured geometric distortion data . The MODIS data processing system will 
include a geometric correction function which will generate estimates of the residual 
biases in the parameters which describe the internal geometry of the MODIS sensor 
and its relationship to the EOS platform (see requirement FN09). The MODIS 
Level 1A process will support this bias estimation by measuring the residual 
geometric error in a subset of the Level 1A products during routine product 
generation. These distortion measurements will be analyzed at the TLCF to improve 
the accuracy of and to track variations in the sensor geometric correction parameters 
over time. Improved values of the geometric correction parameters will periodically 
be provided to the DADS for archive as an ancillary data set. 

4.1,2 Scheduling, Control, Monitoring, and Accounting (SCMA) 

The SCMA activities, included as part of the ECS PGS process, interface with the MODIS Level 
1A process in two ways: 1) it serves as control to the MODIS system (it sends messages to the 
MODIS process) and 2) it receives processing status information (messages from the MODIS 
process). This messaging performs five functions: 1) the initiation of execution, 2) the 
suspension of execution, 3) the resumption of execution, 4) the cancellation of execution, and 
5) the requesting of status processing information. Reprocessing will be performed as part of the 
’initiation of execution’, function number 1) above. 

• IF04: Initiate Execution. The MODIS Level 1A process shall accept an initiation 
message from the ECS PGS indicating the mode of processing and identification of 
input data, as predefined by the MODIS instrument team . The MODIS process (a 
process is a program in execution) obtains this message from the SCMA before any 
other processing steps have been taken. This message will contain the MODIS 
processing mode (standard, reprocessing, or quick look), input file names (or file 
pointers for the Level 0 or Level 1A to be reprocessed if applicable), and data 
descriptors (orbit number, TDRSS contact number, data quantity, etc.). This allows 
the MODIS process to calculate the sizing of the output product. 

• IF05: Cancel Execution. The MODIS Level 1A process shall have the ability to 
terminate execution upon receipt of a termination signal from the ECS PGS . The 
MODIS process will have the ability to perform an orderly abort in which the 
datasets are properly posted and closed, processing log entries are posted, and 
Metadata are fully appended. This is contrasted with a normal termination in which 
the MODIS Level 1A process automatically posts and closes MODIS generated 
datasets and passes ownership of those datasets to the PGS Product Manager. 
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• IF06: Post Processing Termination Report. The MODIS Level 1A process shall 
generate a report to the PGS containing final accounting information . This is the final 
accounting message to the SCMA, after all processing has been completed and all 
resources (memory, files) have been de-allocated (posted and closed), that indicates 
the termination status of the MODIS process. It is posted to the SCMA upon MODIS 
termination. This accounting message contains an indication of the quality of the 
output data products , being careful not to duplicate information automatically 
generated by the PGS toolkit. 

• IF07: Alarm Messages. The MODIS Level 1A process shall have the ability to 
generate alarm messages in the event of data or instrument problems . This class of 
messages indicates that a serious problem has occurred within the MODIS process 
that could lead to the generation of invalid data. The contents of the message 
indicates the nature and severity of the problem. The message is expected to contain 
indicator flags with predetermined error types in addition to ASCII contents . These 
messages are also logged to the MODIS processing log. 

• IF08: Event Messages. The MODIS Level 1A process shall generate messages for 
informational nurposes . This is a class of messages that are informational in nature 
and do not affect the quality of the output data products. These messages are also 
posted to the MODIS processing log. A usage example of this facility might inform 
the Advanced Spacebome Thermal Emission and Reflection (ASTER) team of 
MODIS-detected volcanic activity. 

• IF09: The MODIS Level 1A process shall use as input only those parameters and 
input datasets as directed bv the ECS PGS (scheduler) . 

• IF10: The design of the MODIS Level 1A processing system shall not p reclude the 
concurrent execution of multiple processes . 

4.1.3 Product Management System (PMS) 

This function, within the PGS, provides the PGS with the opportunity of accessing the MODIS 
Level 1A output data products, appending externally generated Metadata parameters, and 
transferring the data products to the appropriate DADS. 

• IF21: MODIS Level 1A Standard Data Product. The MODIS Level 1A process 
shall create the MODIS Level 1 A Data Product . The MODIS Data Product contains 
all instrument data, as opposed to the metadata product which contains descriptors 
that synopsize the contents of the Data Product. The requirements for the content of 
this output product is further described in section 5.1.2 of this document. A 
performance issue to be considered would be the shared staging of the output 
products for the convenience of the remaining processes in the MODIS processing 
chain before conversion to the HDF format. 

• IF22: MODIS Level 1A Quick Look Data Product. The MODIS Level 1A process 
shall create the MODIS Level 1A Quick Look Data Product. The Quick Look 
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product will have the same format as the standard Data Product, but will not be as 
rigorously quality tested or padded to full orbit boundaries. It will contain an integer 
number of full scan cubes and a quick look identification in the Data Product header. 

• IF23: MODIS Level 1A Output Metadata. The MODIS Level 1A process shall 
create the MODIS Level 1A Metadata . The MODIS Metadata contains a synopsis of, 
and descriptors for the associated MODIS Data Product. Level 1A Metadata consists 
of the Level 0 Metadata (EDOS accounting) to which the Level 1A information is 
appended. The specific contents of the MODIS Level 1A Metadata will be defined 
by the EOS project and the MODIS science community. The metadata requirements 
are further described in section 5.1.2 of this document. 

• IF24: MODIS Level 1A Output Product Integrity. The MODIS Level 1A process 
shall appropriately post the output data to non volatile storage . At processing ’check 
points’, the MODIS Level 1A process will write the current data from memory to 
the storage media. This will allow a minimum of reprocessing to be performed in the 
event of an abort (for example, a power failure). For example, the check point could 
be at the completion of one or more scan cubes and would post both the Data 
Product and the Metadata. 

4.1.4 MODIS Log 

This entity supports the availability of current MODIS processing knowledge to the various 
Science Computing Facilities (SCF) and the MODIS Team Leader Computing Facility (TLCF). 
Processing knowledge includes the temporal and spatial extent of acquired MODIS data, error 
conditions encountered, instrument and processing modes, processing and instrument events, etc. 
It is additionally used as an audit trail in the legal sense. 

• IF25: MODIS Processing Log. The MODIS Level 1A process shall post all 

relevant processing information to the MODIS Processing Log, in order to track 
product generation history . This MODIS log, either common to all the MODIS 
processes or unique to each MODIS process, contains an audit trail of time ordered 
MODIS processing events. The contents of this log file are written by MODIS 
processes and can be examined, but not altered, by any other process. The location 
of and access method to this processing file is TBD and may be influenced by 
performance concerns. 

4.2 PGS Assumptions Made by the MODIS Level 1A Process 

These PGS-related assumptions are derived from the current design philosophy as outlined in 
the MODIS Data Rate, Volume, and Structures document. 

• IF26: Time Determination. The MODIS Level 1A process shall be able to obtain 
the current time . The current time is used to time stamp the entries into the MODIS 
processing log and the processing times in the data products. 
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• IF27: Time Conversion. The MODIS Level 1A process shall be able to convert 
among time bases . Conversion among time bases allows the MODIS process to 
convert instrument and spacecraft time into the formats required for the MODIS data 
products. 

NOTE: As the MODIS Level 1A design matures, other assumptions may be made on the PGS. 

5. INTERNAL REQUIREMENTS 

The requirements in this section are directed toward the internal functional aspects of the 
MODIS Level 1A design. Requirements directed toward entities that are external to the MODIS 
Level 1A design are contained in Section 4 of this document. 

5.1 Process and Data Requirements 

The following functional requirements list the categories of functions that the MODIS Level 1A 
process will provide while the data requirements specify the contents of the input and output data 
products. 

5.1.1 Functional Requirements 

• FN01: Level 1A Data Product Reversibility. The MODIS Level 1A Data Product 
shall be reversible to the MODIS Level 0 Data Product as received by the Level 1 A 
process . Reversibility will include all ancillary and engineering data. Packets that do 
not pass the CRC will be thrown away. The MODIS Level 1A process will not alter 
the input data in any way that results in the destruction of any of the original data 
content. This allows the MODIS Level 1A Data Product to be the definitive archived 
product in place of the MODIS Level 0 data packets. 

• FN02: Level 1A Data Product Header. The MODIS Level 1A Data Product shall 
produce a Data Product header for each orbit . A single header data structure will 
be created by the MODIS Level 1 A process and incorporated into each unit (dataset) 
of the output Data Product. Information in the header will be a subset of the 
information in the Metadata. 

• FN03: Level 1A Science Content. The MODIS Level 1A process sh all execute 
limited science software to detect quick reaction events (e.g.. volcanoes or forest 
fires) . The MODIS process will execute simple science software on the raw counts 
values obtained from specified data channels and generate event messages to the ECS 
PGS. For example, this facility can be used for volcano detection to allow the 
ASTER instrument to be scheduled for detailed volcano examination or large scale 
forest fire detection. 

• FN04: Instrument Operating Modes. The MODIS Level 1A processing program 
shall handle all instrument operating modes . The MODIS instrument has two main 
modes of data operation: day mode and night mode, with several sub-modes for 
calibration purposes. The telemetry format has two differing data packet lengths in 
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which several types of data can be contained. For the purpose of creating the Level 
1A Data Product, the two main modes will produce a common scan cube contained 
in a data structure that will accommodate all the types of data produced, including 
the scanned Earth viewing science data, scanned calibration sources, engineering data 
of all types, and the spacecraft platform position and attitude asynchronous data. Data 
structure contents are further specified in the Data Requirements section of this 
document. 

• FN05: Data Transmission Modes. The MODIS Level 1A process shall process 
quick look and standard MODIS Level 0 data transmissions . The MODIS quick look 
data are designated by a quick look flag within the data packets. It is used by the 
EDOS store and forward switching system to facilitate the timely routing of MODIS 
packets to the MODIS Level 1A process. There are currently no design requirements 
for the quick look data that are different than normal standard processing other than 
a relaxation of the quality checking and a descriptor in the header indicating that the 
output Data Product is a quick look product. Having the standard and quick look data 
processing in a common executable insures that a single set of software is employed. 

• FN06: Level 1A Metadata Philosophy. The output MODIS Level 1A Metadata 
shall contain all the MODIS Level 0 metadata with Level 1A information appended . 
The Level 1A Metadata Product will be a super set of the input Level 0 accounting 
data (Level 0 Metadata). The philosophy of Metadata products is to keep as much 
relevant information as possible to allow quick, self-contained, determination of the 
processing history or pedigree of the each Data Product. This will be facilitated at 
each processing stage by retaining the prior metadata and appending the new 
processing information. The Metadata contents are delineated in the following 
section. 

• FN07: Level 1A Earth Location. The MODIS Level 1A process shall generate 
Earth locations for each spatial element in the output product . The MODIS Level 1A 
process will compute geodetic positions, satellite vectors, and solar angles for each 
spatial element (1 kilometer IFOV) in the Level 1A dataset. These Earth locations 
will be based on the best ancillary data available. These ancillary datasets include 
geometric correction parameters provided by the MODIS geometric correction 
activity, refined platform orbit and attitude data generated by the Flight Dynamics 
Facility for selected orbits, and terrain elevation data supplied by the EOS project. 
Although the Level 1A process will provide the capability to use ancillary data from 
external sources when available, it will also be capable of generating nominal 
geolocation data in the absence of any of the ancillary datasets using solely the Level 
0 data. The source and quality of the ancillary datasets will be indicated in the data 
product header and quality arrays respectively. 

• FN08: Level 1A Reprocessing. The MODIS Level 1A process shall reprocess 

Level 1A products without repeating unnecessary steps for the following cases : 

- FN08A: Level 1A Science Data Reprocessing. When the Level 1A process is 
rerun on existing Level 1A MODIS science data, for example, to perform 
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additional data quality checks incorporated in a new revision of the Level 1A 
software, it shall have the capability to use the existing geolocation data rather 
than regenerating it. 

- FN08B: Geolocation reprocessing using improved instrument or platform 

information. Knowledge of the internal instrument geometry and the sensor to 
platform alignment will improve with time as the MODIS instrument is better 
characterized. Datasets which have already been processed to Level 1A may be 
reprocessed to take advantage of this better geometric correction data or of more 
accurate ephemeris or attitude data. This reprocessing will start with Level 1A 
input data and will replace only the Earth location portion of the Level 1A 
dataset. 

- FN08C: Geolocation reprocessing using improved digital elevation data. The 
quality of the ancillary digital elevation and geoid data used to generate the 
Level 1A Earth locations will improve over time as the global DEM is refined. 
Previously processed Level 1A datasets may be reprocessed to take advantage of 
this improved ancillary data. This reprocessing will use the existing geolocation 
information as a starting point from which to compute refined Earth locations, to 
reduce the processing load. 

• FN09: MODIS Geometric Correction. The MODIS Level 1A process shall use 
ground control points to measure residual geometric error, to support the estimation 
of static and slowly varying biases in the platform and instrument geometry . Residual 
biases in the prelaunch values for the parameters which describe the internal 
geometry of the MODIS sensor and its relationship to the EOS platform as well as 
unknown but characterizable dynamic errors, will limit the accuracy of the Earth 
locations generated for MODIS Level 1A data products at launch. The MODIS data 
processing system will include analysis tools that support an ongoing geometric 
correction effort to estimate the static biases and monitor their stability, and measure 
the magnitude, time persistence, and repeatability of the dynamic geometric errors 
affecting the MODIS Level 1A data products. This geometric error analysis will 
utilize SRC A data and data from external sources such as ground control points. The 
MODIS Level 1A process will use control points to measure the residual geometric 
error in selected products. The off-line geometric analysis activity will use multiple 
sets of these error measurements to estimate geometric correction parameters. 
Improved estimates of the MODIS geometric correction parameters will be provided 
to DADS for archive on a periodic basis. The frequency with which datasets must 
be analyzed is TBD. 

5.1.2 Data Requirements 

• FN10: Level 0 Input Data Checking. The MODIS Level 1A process shall perform 
input packet data checking of the following items : 

- FN10A: The Level 1A process shall verify the MODIS instrument data packet 
CRC. This is a check to insure that the packet information is valid. Packets that 
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do not have a valid CRC will be discarded. The packet ID, sequence count, or 
other data identifiers can not be trusted if the CRC computes incorrectly and the 
location of the packet within the scan cube can not be determined. 

- FN10B: The Level 1A process shall verify packet IDs, sequence counters, packet 
sizes, and packet format. Packet IDs, sizes, and sequence counters will be used 
by the Level 1A process to properly place the packet data into the appropriate 
scan cube data structure. Packet formatting will be used to identify data 
components. 

- FN10C: The Level 1A process shall check and account for duplicate packets. 
Although the standard EDOS processing will remove duplicate packets, the quick 
look EDOS processing on multiple TDRSS down links may produce duplicate 
packets. Missing packets will be flagged in the output MODIS Level 1A Data 
Product. 

Appropriate responses to the PGS will be generated if the process detects anomalies related to 
the above data checks. 

• FN11: MODIS Level 1A Data Product Header Contents. The MODIS Level 1A 

Data Product header shall contain information such as : 

- FN1 1 A: Address of the origination source. A complete description of the project 
(with contact information) which can be used to obtain all information about the 
dataset. 

- FN1 IB: Project name. The name of the logical division within the project for the 
parties responsible for the dataset and its contents. 

- FN1 1C: Date of the last dataset revision. Full-time stamping of the last time this 
dataset has been altered. 

- FN11D: Software, Level 0, and ancillary data revision codes. Full descriptors 
of the revision of the software utilized to create this dataset. 

- FN11E: Quantitative descriptors (selected metadata) of the Data Product 

contents. An indication of the contents of the dataset, specifying (for example) 
that the dataset is a remotely sensed image of the Earth in specified spectral bands 
covering a specified range of latitudes and longitudes in 1 km pixels for specified 
dates. 

- FN1 IF: Data Quality Descriptors. A synopsis of the data quality arrays that will 
be contained within each scan cube. 

This facility allows the dataset to be interrogated by simple ASCII editors or listers and 
sufficient information to be extracted by these simple editors or listers to determine the type, 
origination, and contents of dataset. 
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• FN12: MODIS Level 1A Metadata Contents. The MOD1S Level 1A Metadata 

output product shall contain, as a minimum, the following : 

- FN12A: All EDOS accounting information. A possibly reformatted copy of the 
EDOS accounting information that is contained in the EDOS final accounting 
packet. 

- FN12B: EOSDIS specified contents. Metadata contents that are required of all 
DADS Metadata. These may be specified by EOS, the Consultative Committee 
on Space Data Systems (CCSDS), or other authorities. 

- FN12C: Descriptors about the MODIS Level 1A Data Product. The contents of 
the Metadata Product will be specified at a later date by both the ECS project and 
the MODIS community. 

- FN12D: Information describing the temporal and spatial domain of the dataset. 
A common mechanism for describing the spatial and temporal extent of archived 
datasets should be specified by the EOS project to support Information 
Management System spatial queries. 

- FN12E: All of the Data Product header contents. A repeat of all the information 
that will be contained in the MODIS Level 1A Data Product header. Reformatting 
of the header contents may be required to match Metadata content formats. 

- FN12F: Descriptors About the Level 1A geolocation Processing. Information 
about the sensor geometric correction parameters, the source of the platform orbit 
and attitude data, and the accuracy of the DEM data used in the MODIS Level 
1A Earth location processing will be included in the Level 1A metadata. 

- FN12G: Parametric Earth Location coefficients. The coefficients of a simple 
model which relates image pixel and line number to the corresponding location 
at the Earth ellipsoid surface and vice versa will be included in the metadata for 
each Level 1A dataset. This parametric geolocation model will provide a method 
for rapidly indexing into the MODIS Level 1A dataset based on Earth 
coordinates. 

- FN12H: Input and Ancillary File Traceability . This metadata content requirement 
satisfies the criteria for the reproducibility of data as well as the tracking of the 
product generation history. It is beneficial to data users to be able to reconstruct 
the process, including software and dataset versions, that produced the Level 1A 
data to the fullest extent possible. 

The Metadata are the repository for all information about the actual Data Product. It can be used 
as selection criteria to delineate among the various data products. Metadata will also include 
subjective comments in addition to objective independent observation about the corresponding 
Data Product. There is a one to one correspondence between the Metadata sets and the 
associated Data Product datasets. 
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• FN13: MODIS Level 1A output Data Product Formatting. The MODIS Level 1 A 

data product shall conform to the EOSDIS standards for data structures and formats. 

• FN14: MODIS Level 1A Data Product Attributes. The MODIS Level 1A Data 

Product shall possess the following attributes : 

- FN14A: A unit (dataset) of a MODIS Level 1A standard Data Product shall 
consist of a full orbit of data. This is the dataset unit for each occurrence of the 
output data products. The smallest obtainable data unit (granule) within a dataset 
occurrence will be a scan cube. 

- FN14B: A unit (orbit) of data shall begin at the beginning of the first full scan 
cube after the nighttime node. An orbit boundary will occur during the MODIS 
nighttime operating mode. 

- FN14C: Partial units and missing data shall be padded with fill data. All data are 
preallocated and filled with a default invalid data value when the storage for each 
scan cube is allocated. This occurs before any real data are placed in the allocated 
scan cube. 

- FN14D: A unit (orbit) of data shall contain full, complete (integer number of) 
scan cubes. Scan cubes will not be split or duplicated across Data Product units. 

- FN14E: All data shall be byte aligned. This follows from the use of the HDF 
archiving criteria. No requirement for a 12 bit data type will be imposed on the 
HDF library and the MODIS Level 1A process will unpack the all 12 bit data to 
16 bit words. 

• FN15: MODIS Level 1A Data Product Contents. The MODIS Level 1A Data 

Product shall contain the following information : 

- FN15A: Raw science data. Earth-viewing, moon-looking if the spacecraft has 
been tilted. 

- FN15B: Raw Solar Diffuser data. When solar diffuser is deployed; otherwise, 
electronic calibration data. 

- FN15C: Raw Black Body data. Ambient or heated blackbody views. 

- FN15D: Raw Space View data. Deep space viewing; occasional lunar views. 

- FN15E: Band number to data channel number translation tables. To allow for the 
two gains of bands 13 and 14, and the smaller spatial viewing of bands 1 through 
7. 
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- FN15F: Spatial data quality arrays. Across track vs. along track, and along track 
vs. data channel to allow quality indicators to be specified at the level of each 
pixel, band, and detector. 

- FN15G: Two Time Tags per frame. 

- FN15H: Spectroradiometric Calibration Assembly (SRC A) and Solar Diffuser 
Stability Monitor (SDSM) Data (TBD). 

- FN15I: Engineering/Memory Dumps (TBD). 

- FN 1 5 J : Spacecraft Position and Attitude . Sufficient platform location and attitude 
data values, clustered in time about each scan cube to allow for time based 
interpolation. 

- FN15K: Spatial Element Geodetic Coordinates. The geodetic latitude, longitude 
and height at which the sensor line of sight intersects the terrain surface for each 
spatial element (1 kilometer IFOV) in the Level 1A dataset. 

- FN12L: Spatial Element Satellite Vector. The zenith angle, azimuth and range to 
the satellite for each spatial element in the Level 1A dataset. 

- FN12M: Spatial Element Sun Angles. The solar zenith angle and solar azimuth 
for each spatial element in the Level 1A dataset. 

5.2 Performance and Quality Engineering Requirements 

The requirements in this section relate to the performance constraints of the MODIS Level 1A 
process and include items that result in better partitioning of the processing task and improved 
processing speed. 

• PR01: Processing Timeliness (PGS parent requirement). The MODIS Level 1A 
data product generation shall be completed within 24 hours of the arrival of the Level 
Q data . This Level 1A data product timeliness requirement is imposed primarily on 
the PGS scheduling activity. 

• PR02: Data Throughput Rates (PGS requirement) . The MODIS Level 1 A process 
shall process a full dav of input data and generate output data products in a TBD 
fraction of a dav . 

• PR03: Error Detection. The MODIS process shall continue processing upon the 
detection of an condition . The MODIS processing software, in conjunction with the 
PGS Tool Kit, will trap and properly process all exceptions that may produce an 
abort condition. These processing events will be posted to the MODIS processing 
log. 
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• PR04: Data Quality. The MODIS Level 1A process shall perform (TBD) data 
quality checking on the output MODIS Level 1A Data Product . Selected data values 
in the content of the output Data Product will be validated using techniques and 
criteria that will be specified at a future time. This will produce a data quality array 
as part of the output MODIS Level 1A Data Product. The quality array will include 
one or more subfields which reflect the accuracy of the Earth location data. 

• PR05: Data Product Granularity. The MODIS Level 1 A process shall provide data 
quality indicators for each scan cube . Every scan cube of output product will contain 
data quality arrays and indicators for data that is scan-cube related. 

• PR06: Maintainability. The MODIS software shall be documented and 

configuration managed . Full configuration management in a distributed heterogeneous 
computer network will be implemented to enable revision control across the TLCF, 
SCFs, and ECS computer systems. 

• PR07: Portability. The MODIS software shall be written according to EOSDIS 
standards . Vendor-dependent language extensions will not be used (see design goals). 

• PR08: Use of PGS Toolkit. The MODIS software will use a subset of the tools 
provided by the PGS toolkit as appropriate. To reduce the cost and schedule risk to 
the project, the SDST recommends that EOSDIS provide the calling sequences of the 
tools in the toolkit as early as possible in the development life-cycle. 

• PR09: Earth Location Accuracy. The MODIS Level 1A process shall have an 
absolute Earth location accuracy goal of 0. 1 IFOV for the nominal 1 km resolution 
bands . The absolute accuracy of the Earth locations generated by the MODIS Level 
1A process is primarily dependent on the quality of the geometric correction, orbit, 
attitude, mirror, and DEM input data. Excluding DEM errors, the MODIS 
processing system will seek to achieve the 0. 1 IFOV accuracy goal by improving the 
at-launch knowledge of the static and slowly vaiying components of error through 
an ongoing geometric correction activity. The frequency with which the error 
estimation analysis must be performed to meet this goal is TBD. 

5.3 Safety Requirements 

• OROl: All MODIS Level 1A operational software will be under the control of the 
ECS, which will be responsible for all safety concerns. Critical tasks, operator 
intervention, processing analysis, and human factors are all ECS functions. 

5.4 Security Requirements 

• OR02: The controlled access to data and processing elements, data protection and 
recovery, and privacy issues are the responsibility of the ECS. 
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5.5 Implementation Constraints 

• OR03: The MODIS implementation will be performed on the MODIS TLCF and 
ported to the PGS when that computer system has been placed into operation. The 
MODIS SDST has no current knowledge of the computer system or computer 
architecture to be selected. 

• OR04: MODIS requires the availability of Level 0 datasets that have known data 
values and discrepancies for testing purposes during development on the TLCF and 
subsequent porting to the PGS. 

• OR05: MODIS also requires an independent output product data validator. 

These requirements are covered in documents written under different covers. 

5.6 Site Adaptation 

The MODIS Level 1 A processing software will be fully encapsulated within the PGS tool kit and 
will therefore have no direct contact with other processes or the operating system. 

5.7 Design Goals 

The MODIS Level 1A process will satisfy all the requirements as set forth in this document. It 
will be tested in conjunction with a Level 0 packet simulator and a Level 1A data product 
validator. The packet simulator will include the ability to generate pseudo instrument data, 
accept instrument engineering model data, modify packet parameters, include simulated scene 
data, provide valid spacecraft position and attitude information, and alter selected engineering 
data. The data validator will display selected engineering data, visualize scene image data, 
display headers, and generate statistics. The goal of these testing systems is to create the highest 
reliability in the MODIS Level 1A process software. 

All MODIS software components shall contain commented information that can be automatically 
extracted and made available to all software personnel in utilizing a common access method. Key 
words will be used in the software modules that will allow for the machine extraction of parts 
of the common software headers and other commented sections. These will be placed into a 
project accessible database for use by all personnel and will facilitate the reuse of previously 
written modules. 

The MODIS software shall be generated with machine and architecture porting as a primary 
goal. Consideration shall be given to facilitate portability from machine to machine when 
designing and writing the Level 1A software. The functional modules of the MODIS software 
will utilize techniques that allow for their transfer to other technologies and disciplines such as 
real time monitoring in addition to the core requirement of the PGS implementation. 
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6 . 


TRACEABILITY TO PARENT’S DESIGN 


The requirements in this document are derived from the EOS Program Level 1 Requirements 
and the Implementation Agreement for the MODIS Team Leader, Statement of Work 
Execution/ Operations Phase. 

The MODIS Level 1A Processing is part of the overall MODIS Science Data Processing. The 
Context Diagram shown in Appendix A illustrates the relationship of the external entities to the 
MODIS Science Data Processing. The Layer 0 DFD shows the context of the Level 1A 
Processing with respect to the Level IB, and Higher Level Processing in the MODIS Science 
Data Processing Software Suite. 

7. PARTITIONING FOR PHASED DELIVERY 

The MODIS Science Team Leader has assigned responsibility to the MODIS SDST for all 
aspects of the development of the MODIS Level 1A software. The development plan is based 
upon three phases, or software versions, /3, VI and V2 prior to launch. The purpose of the three 


phases is to: 


• 

0 

Test migration from the SCF to the EOSDIS, exercise interfaces, and test 
execution in the operational environment. 

• 

VI 

Correct any problems in the 0 Version, complete operator interface, 
generate all messages. 

• 

V2 

Software ready for launch. Final integration, test of operations procedures, 
training of operations staff. 


The SDST schedule for development of the three phases of MODIS Level 1A science software 
is given in Appendix B. The software requirements, design, and code will be developed as an 
iterative process involving the MODIS Science Team members. There will be substantial 
changes in going from 0 to V2. 

The SDST will develop a Level 1 Test Plan and test datasets which will exercise all of the viable 
branches (within reason) in the code, checking for proper results. The tests will also check for 
proper functioning of the software in the presence of anomalous or meaningless data. 

After the software has been thoroughly tested on the TLCF, the SDST is responsible for porting 
the software to the EOSDIS PGS and participating in the test process in the PGS. 
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8. ACRONYMS AND ABBREVIATIONS 


ASTER 

CASE 

CCB 

CCR 

CCSDS 

CRC 

DAAC 

DADS 

DEM 

DFD 

ECS 

EDOS 

EOS 

EOSDIS 

GSFC 

HDF 

IMS 

IR 

MODIS 

PDR 

PGS 

PM 

PMS 

QA 

RDC 

SBRC 

SCF 

SCMA 

SDSM 

SDST 

SRCA 

SRR 

TDRSS 

TLCF 


Advanced Spacebome Thermal Emission and Reflection 

Computer Aided Software Engineering 

Configuration Control Board 

Configuration Change Request 

Consultative Committee on Space Data Systems 

Cyclic Redundancy Check 

Distributed Active Archive Center 

Data Archive and Distribution System 

Digital Elevation Model 

Data Flow Diagram 

EOSDIS Core System 

EOS Data and Operations System 

Earth Observing System 

EOS Data and Information System 

Goddard Space Flight Center 

Hierarchical Data Format 

Information Management System 

infrared 

Moderate-Resolution Imaging Spectroradiometer 

Preliminary Design Review 

Product Generation System 

Product Management 

Product Management System 

quality assurance 

Research and Data Systems Corporation 

Santa Barbara Research Center 

Science Computing Facility 

Scheduling, Control, Monitoring, and Accounting 

Solar Diffiiser Stability Monitor 

Science Data Support Team 

Spectroradiometric Calibration Assembly 

Systems Requirements Review 

Tracking and Data Relay Satellite System 

Team Leader Computing Facility 
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9. 


GLOSSARY 


ALGORITHM is a general or abstract approach to solving a problem. An outline of major steps 
to be taken in the solution expressed in English (or other natural language) and/or in pseudo- 
code/PDL. 

ANCILLARY DATA refers to any data, other than Standard Products, that are required as input 
in the generation of a Standard Product. This may include selected engineering data from the 
EOS platform, ephemeris data, as well as non-EOS ancillary data. All ancillary data are received 
by the PGS from the DADS. 

AT-LAUNCH PRODUCTS are data products for which science software is scheduled to be 
completed and operational at launch time. Generation of the at-launch products will begin as 
soon as data are available. 

BAND is a center frequency and filter function width combination that are referenced by an 
arbitrary number. One channel usually measures data from one band, but MODIS has two 
channels of data for each of bands 13 and 14. 

(3 VERSION SOFTWARE is the preliminary version of software used to test migration from the 
SCF or TLCF to the EOSDIS, exercise interfaces and test execution in the operational 
environment. 

BROWSE DATA are subsets of a dataset other than the directory and metadata that facilitates 
user selection of specific data having the required characteristics. For example, for image data, 
browse data could be a single channel of multichannel data, and with degraded resolution. The 
form of browse data is generally unique for each type of dataset and depends on the nature of 
the data and the criteria used for data selection within the related science discipline. 

CALIBRATION is the process of removing biases from the measurements. The information 
required to perform calibration of the instrument science data will include instrument engineering 
data, spacecraft or platform engineering data, pre-flight calibration measurements, in-flight 
calibrator measurements, ground truth data, and calibration equation coefficients derived using 
calibration software. 

CHANNEL is the data derived from an instrument data gathering electronic channel. Channels 
of data may be obtained in parallel. Contrast this with a band of data. 

CORRELATIVE DATA are scientific data, generally from outside sources, needed to evaluate 
and validate EOS data products. 

DATA QUALITY REQUEST is a request issued by the PGS to a scientist at an SCF to perform 
quality assurance (QA) of a particular product before future processing or distribution. A time 
window is applied to the request in keeping with the production schedule. 

DIGITAL ELEVATION MODEL refers to a numerical model which describes the elevation of 
the Earths terrain surface above mean sea level. In the Level 1A processing context, it includes 
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no higher order terrain statistics, such as slope, although these may be required for some 
MODIS Level 2 data products. Global digital elevation data have been identified as a required 
ancillary dataset by several of the EOS AM instruments. 

DOCUMENTS are the hardcopy or digitized references or records about a science software, or 
the data products generated by the science software. These shall be archived at the DADS. 

EXECUTABLE is the result of compiling and linking a program written in a standard 
programming language such as C or Fortran. An entity whose action can be invoked directly 
from the UNIX command line. 

FRAME is a set of data representing one instance of: all bands of science data and 10 along 
track spatial elements (day or night mode), or all bands & 10 spatial elements of solar diffuser, 
black body, or space view data, or specialized data from the SRCA or Engineering/Memory 
dumps. 

GEOMETRIC CORRECTION PARAMETERS refer to the set of constants which describe the 
internal geometry of the MODIS instrument and its relationship to the EOS platform (for 
example the sensor to body alignment matrix). These parameters will be known to some 
precision at launch and will be refined post-launch through an ongoing geometric correction 
effort. 

INSTRUMENT DATA are data specifically associated with the instrument, either because it was 
generated by the instrument or included in data packets identified with that instrument. These 
data consist of instrument science and engineering data, and possibly ancillary data. These data 
may be assembled for transmission by the instrument, or by an on-board processor of the 
instrument data. 

INTERACTIVE SESSION DIALOG consists of messages that flow between a scientist at an 
SCF and the PGS that support general communication with the Integration and Test Service. 
This includes logins, mail messages, etc. 

Level 0 DATA are raw instrument data at original resolution, time ordered, with duplicates 
removed. 

Level 1A DATA are Level 0 data, which may have been reformatted or transformed reversibly 
and packaged with needed ancillary, engineering, and auxiliary data. 

METADATA are data which describe the content, format, and utility of a Standard Product. It 
includes standard metadata (i.e. , science software and calibration numbers, size of product, date 
created, etc.), science software-derived metadata, QA information from the Pi’s, summary 
statistics and an audit trail. Metadata are received by each DADS with the corresponding 
datasets. DADS validates it physically, updates it with inventory information, enters it into a 
distributed database (to which the Information Management System (IMS) has access), and 
archives it. Metadata about special products produced at SCFs shall be sent to the DADS along 
with their associated data products. 
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METADATA UPDATES are additional or changed metadata items relating to a previously 
delivered product. 

ON TIME QA is a response to a data quality request that is received within the established 
production time window. It is received from a scientist at an SCF. It consists of data which will 
be used to complete the QA fields of the metadata. Overdue QA responses are sent directly to 
the DADS. 

PIXEL is the smallest decomposed unique science data value. One pixel represents the data from 
one spatial position and one channel of data. 

POST-LAUNCH PRODUCTS are data products for which science software are scheduled to 
be completed at some time after launch. 

PRODUCT GENERATION EXECUTABLE (PGE) is either a single executable that is rebuilt 
at the PGS using the delivered science software, or a set of such executables embedded within 
a script written by the science software developers. For example, the MODIS Level 1 A process, 
with its accompanying script language, could be an example of a running PGE. 

PRODUCTION SCRIPT is a script that is written by the PGS (perhaps automatically by the 
scheduler). A production script controls the execution of one or more PGEs. Some of the content 
of a production script may be based on instructions from the science teams. For example, the 
PGS might create a production script to run the 1A and IB PGEs in sequence. 

QUICK-LOOK DATA are data that carry a quick-look identifier which is initially applied at the 
MODIS instrument in response to a request for quick processing in support of a field experiment 
or other special purpose. Processing is done in near-real-time as the datasets are received using 
the same science software as for normal processing. Calibration and quality assurance 
requirements are relaxed for fast turn-around. Data identified as quick-look are also processed 
in the normal mode with all other data for standard products. 

SCAN CUBE is the three dimensions of the science data: along track, across track, and band 
number with ground locations, engineering data (per scan), and quality indications attached. 

SCIENCE COMPUTING FACILITY is a MODIS science team member’s computing facility 
to support science software development and testing and generation of MODIS special products. 

SCIENCE DATA SUPPORT TEAM is the software support group designated by the MODIS 
Science Team Leader to develop MODIS science data processing requirements, develop MODIS 
Level 1 processing software, develop the higher-level processing shell, support the integration 
of team members’ science software into the production environment, and provide support for 
the development of required plans and documentation. 

SCIENCE SOFTWARE is the complete suite of items delivered by the science team to the PGS. 
This includes source code, build instructions (i.e., make files), documentation, test data, test 
procedures, and sample test results. This is the most likely replacement for "algorithm" in the 
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old usage. For example, we now refer to Science Software Development or Science Software 
Integration and Test. 

SCIENCE SOFTWARE UPDATES are delivered to the PGS’ integration and test environment 
by scientists at a SCF. They represent changes to existing production science software, or new 
science software to produce new Standard Products. Science software updates include the source 
code for the candidate science software, its associated documentation, a job step control 
skeleton, test datasets and expected test results. 

SCRIPT is a set of instructions written in a structured language, similar to a UNIX shell 
language. 

SPATIAL ELEMENT refers to the area covered by a single sensor instantaneous field of view 
(for the 1 kilometer bands) for a nominal detector in a nominal band. A single spatial element 
corresponds to the pixels from all bands for a given spatial position. Corrections for real band 
and detector misalignments from their nominal locations will be applied during Level 3 
processing. 

SPECIAL PRODUCTS are special science data products consisting of Level 1A, Level IB, 
Level 2, Level 3, and Level 4 which are produced at the SCF or the TLCF. (See also Standard 
Products.) These shall be archived at the DADS and distributed to authorized requestors. 

TEAM LEADER COMPUTING FACILITY is the SCF designed to provide the required 
computer support for the MODIS team leader. The TLCF will support MODIS Level 1A and 
IB science software development, development of the higher-level processing shell, integration 
of team members’ science software, generation of special products, science software testing, 
etc. 

VERSION 1 SOFTWARE is used to correct any problems in the 0 Version, complete operator 
interface, generate all messages. 

VERSION 2 SOFTWARE is ready for launch. It will be used for final integration, test of 
operations procedures, training of operations staff, etc. 
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MODIS Data Processing System 








m 



TITLE: 

Verify Level 0 


INPUT/OUTPUT: 

LO_packets : datajn 
LO_verified_lnformation : data_out 
EDOS_accounting : data_out 
processing_status : data_out 

BODY: 

Read LO packets 
Verify LO packets 

check for duplicates 
check packet IDs for MODIS 
check sequence counters 
check packet sizes 
check packet format 
check MODIS packet CRC 
Produce L0_verif ied_information 
Produce EDOS_accounting 
Report processing_status. 
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Accumulate Scan Cubes 


TITLE: 

Accumulate Scan Cubes 

INPUT/OUTPUT: 

L1A_scan_cube : datajn 
L1A_orbit : data_out 
processing_status : data_out 

BODY: 

Read LlA_scan_cube until orbit's worth of data 


Format and Output LlA_orbit 
Report processing_status 
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Write Metadata 


TITLE: 

Write Metadata 

INPUT/OUTPUT: 

geolocation_metadata : datajn 
L1A_scan_cube : datajn 
EDOS_accounting : datajn 
level_1A_metadata : data_out 

BODY: 

Read EDO S_ac counting 
Read LlA_scan_cu be 
Read geolocation_metadata 

Compile metadata (the contents of the metadata are TBD) 
Produce level_lA_metadata 



Perform Quality Checking 


TITLE: 

Perform Quality Checking 

INPUT/OUTPUT: 
L1A_scan_cube : datajn 
processing_status : data_out 
sensor_data_quality : data_out 

BODY: 

Perform TBD Quality Checking. 
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Geolocate Level 1A Orbit 



Read and Validate LO Engineering Da 


TITLE: 

Read and Validate LO Engineering Data 

INPUT/OUTPUT: 

L1A_orbit : datajn 
L1A_engineering_data : data_out 

BODY: 

Read engineering data frames 
Extract spacecraft ancillary messages 
Verify ancillary data messages 

Time order ancillary data messages 
Eliminate duplicate messages 
Extract and validate ancillary message subfields 
Extract orbit data 
Validate orbit data 
Extract attitude data 
Validate attitude data 
Extract solar vectors 
Validate solar vectors 

Extract mirror data from engineering data frames 

Validate mirror data 

Extract scan timing data 

Validate scan timing data 

Write LlA_engineering_data 

Report processing status. 
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Receive Orbit and Attitude Data 


TITLE: 

Receive Orbit and Attitude Data from PGS 

INPUT/OUTPUT: 
orbit_attitude_data : datajn 
L1A_engineering_data : data_out 

BODY: 

Read orbit_attitude_data pointer 
If not null 

Read orbit data 
Subset orbit data 
Validate orbit data 
Read attitude data 
Subset attitude data 
Validate attitude data 

Add orbit /attitude data to LlA_engineering_data 
Update orbit/attitude data flag 
Write orbit to LlA_engineering data 
Write attitude to LlA_engineering_data 

End if 

Report processing status 
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geometric_correction_data 
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Geolocation Level 1A Pixels 



Intersect LOS with Ellipsoid 


TITLE: 

Intersect LOS with Ellipsoid 

INPUT/OUTPUT: 

L1A_engineering_data : data_in 
geometric_correction_data : datajn 
pixel_ellipsoid_coordinates : data_out 

BODY: 

Read orbit data 
Read attitude data 
Read geometric_correction_data 
For each scan 

Read mirror data 
Read scan time 
For each data frame 

Compute imaging time 
Interpolate orbit 
Interpolate attitude 
Interpolate mirror position 
For each pixel 

Construct sensor line of sight 
Solve look point equation 

End loop 

End loop 

Write pixel_ellipsoid_coordinates 

End loop 

Report processing status 
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Compute Ellipsoid Heights 


TITLE: 

Compute Ellipsoid Heights 

INPUT/OUTPUT: 

pixel_ellipsoid_coordinates : datajn 
geoid_data : data_in 
DEM_data : datajn 
ellipsoid_height_data : data_out 

BODY: 


Read pixel_ellipsoid_coordinates 
Determine region of interest for L1A data 
Get geoid_data for L1A region from PGS 
Get DEM_data for L1A region from PGS 
Convert DEM elevations to ellipsoid heights 
Write ellipsoid_height_data 
Report processing status 
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Correct LOS for Terrain 


TITLE: 

Correct LOS for Terrain 

INPUT/OUTPUT: 

L1A_engineering_data : data_in 
pixel_ellipsoid_coordinates : datajn 
ellipsoid_height_data : data_in 
pixel_geodetic_coordinates : data_out 
geolocation_metadata : data_out 

BODY: 

Read orbit data 
For each scan 

Read pixel_ellipsoid_coordinates 
For each data frame 

Compute imaging time 
Interpolate orbit 
For each pixel 

Construct line of sight 
Iterate to convergence 

Interpolate ellipsoid height 
Solve look point equation 
End iteration 

End loop 

End loop 

Write pixel_geodetic_coordinates 

End loop 

Write geolocation_metadata 
Report processing status 
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Compute Solar and Satellite Angle 


TITLE: 

Compute Solar and Satellite Angles 

INPUT/OUTPUT: 

L1A_engineering_data : datajn 
pixel_geodetic_coordinates : datajn 
pixelJook_angles : data_out 

BODY: 

Read orbit data 
Read sun vectors 
For each scan 

Read pixel_geodetic_coordinates 
For each data frame 

Compute imaging time 
Interpolate orbit 
Interpolate sun vector 
For each pixel 

Compute satellite zenith angle and azimuth 

Compute satellite range 

Compute solar zenith angle and azimuth 

End loop 

End loop 

Write pixel__look_angles 

End loop 

Report processing status 
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Compute Earth Location Coeff 


TITLE: 

Compute Earth Location Coefficients 

INPUT/OUTPUT: 

pixel_ellipsoid_coordinates : data_in 
LI A_earth _location_coefficients : data_out 

BODY: 

P-Spec empty. 
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Append Geolocation Data to Level 1 A 


TITLE: 

Append Geolocation Data to Level 1 A Orbit 

INPUT/OUTPUT: 

L1A_geolocation_data : datajn 
L1A_orbit : data_in 
L1A_geolocated_orbit : data_out 
geolocation_metadata : data_out 

BODY: 

Read LlA_orbit scan cubes 

Read LlA_geolocation_data 

Add geolocation data layers to scan cubes 

Read LlA_orbit header 

Write LlA_geolocated__orbit 

Add LlA_earth_location_coef f icients to geolocation_metadata 
Write geolocation_metadata 
Report processing status 
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Measure Geometric Distortion 


TITLE: 

Measure Geometric Distortion 

INPUT/OUTPUT: 
ground_control_data : datajn 
geometric_correction_data : datajn 
L1A_geolocated_orbit : datajn 
geometric_distortion_data : data_out 

BODY: 

* Use ground control image chips to measure the residual 
geometric error in the L1A product using the 250 meter 
resolution data. * 

Read ground_control_data pointer 
If not null 

Read ground_control_data 

Loop on number of control points 

Extract 250 meter image data from LlA_geolocated_orbit 
Assess control point suitability 
If control point is good 
Measure geometric error at control point 
Add to geometric_distortion_data 
End if 
End loop 

Write geometric_distortion_data 
End if 

Report processing status 
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ancillarygeolocation_data (data flow) * 

♦All geolocation input data not part of level 0 raw data* 

geometric_correction_data + 

DEM_data + 
geoid_data + 

(orbit_attitude_data)+ 

( ground__control_data ) 


control_from_PGS (control flow) = 

LlA_control_from_PGS + 

LlB_control_from_PGS + 
higher_level_control_from_PGS 

♦consists of all control information from the PGS toolkit* 


DEM_data (data flow) = 

♦A model of the Earth's terrain expressed as elevation above 
mean sea level with corresponding data quality information. 
Additional terrain characteristics may be required by other 
processes but the elevation and elevation quality data are 
of interest for Level 1A processing. The precise contents 
(including accuracy and spatial resolution) of this data 
set is TBD. Access to this ancillary data set will be 
provided via the PGS Tool Kit.*. 


EDOS_accounting (data flow) = 

*not-defined* . 


ellipsoid_height_data (data flow) = 

*A representation of the Earth's terrain in the region covered 
by the Level 1A data set, expressed as height above the Earth 
ellipsoid. This is generated by combining the DEM elevation 
data and the geoid separation.*. 


geoid.data (data flow) = 

*A model of the deviation of the Earth geoid from the nominal 
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MODIS_System Data Dictionary 
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Earth ellipsoid surface which provides a numerical representation 
of the mean sea level surface. This is an ancillary data set 
provided via the PGS Tool Kit. This data set will not be 
necessary if the global DEM data are stored as ellipsoid 
heights rather than elevations above mean sea level.*. 


geolocation_metadata (data flow) = 

♦Information describing the geolocation processing, to be 
included in the data set metadata. This includes the source 
of orbit/attitude data used (LO or PGS), the availability 
and quality of terrain information, the geometric 
correction data used, and other TBD fields.*. 


geometric__correction_data (data flow) = 

♦Constants describing the internal geometry of the MODIS 
instrument and its relationship to the EOS platform {e.g. the 
sensor to body alignment matrix, detector offsets, band 
offsets). These parameters will be known to some precision 
at launch and will be refined post-launch through an 
ongoing geometric correction effort.* 


geometric_distortion_data (data flow) = 

’Measured geometric error at ground control points. 

Examples of specific fields include GCP latitude, longitude, 
and height, predicted pixel/line, actual pixel/line, and 
control point image chip correlation statistics. * . 


ground_control_data (data flow) = 

’Image points with known ground positions. Examples of 
specific contents include an image window (chip), latitude, 
longitude, and height of the control point, and the subpixel 
location of the GCP within the image chip.*. 


higher JeveLcontrol_from_PGS (control flow) = 

’Defined as all control of the higher level processing provided 
by the PGS toolki 
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higher Jevel_data .products (store) = 

^Defined as all data products produced beyond level IB.* 

level_2_dataj?roducts + 
level_3_dataj?roducts + 
level_4_data_products 


higher_level_status_to_PGS (data flow) = 

*A11 higher level status returned to the PGS toolkit from the MODIS data 
processing system* 

12_status_to_PGS + 

13_status_to_PGS + 

14_status_to_PGS . 


LO.packets (data flow) = 

*Defined as all level 0 packets in the MODIS dataset.* 

LO_MODIS_packets + 

LO_EDOS_account ing_packets 


LO_verified_information (data flow) = 

*Defined as validated MODIS instrument data. * 

L0_verif ied_sensor__data + 

L0_verif ied_engineering_data + 
time_tag 
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L1_to_L4_MODIS_products (data flow) = 

♦Defined as all MODIS Data Products 

delivered to the MODIS Science Team by the data system.* 

level_lA_datajproduct + 
level_lB_dataj?roduct + 
level_2_data_products + 
level_3_datajproducts + 
level_4_datajproducts 


LI A_control_f rom_PGS (control flow) = 

♦Defined as all control of the L1A processing provided by the PGS toolkit *. 

LI A_earth_location_coefficients (data flow) = 

♦Coefficients of a low order model which describes the 
relationship between image pixel-line coordinates and 
ground coordinates. These coefficients provide rapid 
spatial indexing from ground to image or image to ground ♦. 

LI A_engineering_data (store) = 

♦Platform and sensor data needed to perform Earth location* 

LO_orbit_attitude 
+ LG_solar_vector 
+ LO_scan_mirror_data 
+ LO_scan_time_data 
+ ! orbi t_attitude_data } . 

L1A_geolocated_orbit (store) = 

*L1A data with Earth location information appended* 
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LlA_orbit 

+ pixel_geodetic_coordinates 
+ pixel_look_angles 
+ LlA_earth_location_coeff icients 


L1A_geolocation_data (store) = 

*Earth location data added to L1A product* 


pixel_geodetic_coordinates 
+ pixel_look_angles 
+ LlA_earth_location_coef f icients 
+ geolocationjnetadata . 


L1A_orbit (store) = 

*not-def ined* . 


L1A_scan_cube (store) = 

*The LlA_scan_cube is fully defined in a separate document. See Tom Goff 
of the SDST for further details.* 


L0_verif ied_information + 
sensor_data_guality 


L1A_status_to_PGS (data flow) = 

*not-def ined* . 


LI B_control_f rom_PGS (control flow) = 

‘Defined as all control of the LIB processing provided by the PGS toolkit * 


LI B_status_to_PGS (data flow) = 

‘not-def ined* . 
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leveM A_data_product (store) = 

♦Defined as all level 1A data products 

This is a full orbit's worth of data. The unit will begin 
and end at the ascending node of the orbit. This product 
will be in HDF format.* 

LlA_data_product_header + 

LlA_scan„cubes 


level_1A_metadata (store) = 

*not-def ined* . 

leveM B_data_product (store) = 

level_lB_geolocated_datasets + 
level_lB_calibrated_datasets . 

leveM B_metadata (store) = 

*not-def ined* . 


misc_L1 A_input_data (data flow) = 

♦all other LlA_input_data not included in 
ancillary_geolocation_data* 


misc_L1 A_output_data (data flow) = 

*Other TBD output data created by the L1A 
process excluding geometr ic_distortion_data* . 
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MODIS_level_0_Data (data flow) = 

level_0_instrument_housekeeping + 
levGl_0_science_data + 
level_0_EDOS_header + 
level_0_DADS_header . 

♦The Level 0 Modis Data 
originates in the DADS and is defined as: 

MODIS Instrument Housekeeping 
MODIS Science Data 
EDOS Headers* 


MODISJevel_0_data (data flow) = 

[ MODIS_level_0_data_standard 
I MODIS_level_0_data_quicklook 

] 

♦Defined as a TDRSS contact. This may be a fraction of 
or multiple orbits. 

The Level 0 datasets sent by EDOS may be either the standard production oriented product 
or a quicklook version of the data. The quicklook data is not a fully processed 
level 0 dataset 


MODIS_log_entries (data flow) = 

♦Defined as all log entries made to the MODIS logging 
system. Includes an audit trail of all MODIS Processing.*. 


orbit_attitude_data (data flow) = 

♦Satellite ephemeris and attitude data provided from 
an external source via the PGS Toolkit.*. 


Other_Data (data flow) = 

Other_Input_Data is defined as all other datasets required to process the MODIS data. 


other_higherJevel_input_data (data flow) = 
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other_higher_level_output_data (data flow) = 

*not-def ined* . 


other_input_data (data flow) = 

other__LlA_input_data + 
other_LlB_input_data + 
other_higher_level_input_data . 

♦This represents all the input datasets required to process the MODIS data that 
the science team provides. This may include 
coefs_from_science_team + 
o the r_input_from_sci_t earn + 


other_L1A_input_data (data flow) = 

*A11 input data required for Level 1A data processing not provided by the spacecraft 


misc_LlA_input_data + 
ancillary_geolocation_data 


other_L1A_output_data (data flow) = 

^Additional output data sets created by the MODIS Level 1A process* 

geometric_distortion_data + 
misc_LlA_output_data 


other_L1 B_input_data (data flow) = 

’All input data required for Level IE data processing not provided by the spacecraft 
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other_L1 B_output_data (data flow) = 

•Additional output data sets (other than data products) 
created by the MODIS Level IB process* 


other_L2_input_data (data flow) = 

*A11 input data required for Level 2 data processing not provided by the spacecraft 


other_output_data (data flow) = 

other_LlA_output_data + 
other_LlB_output_data + 
other_higher_level_output_data 

♦This represents all additional output data sets 
created by the MODIS processing system. Examples 
include geometric correction parameters. * 


PGS (data flow) = 

♦Product Generation System compenent of the EOSDIS Core System*. 


pixeLellipsoid_coordinates (data flow) = 

♦The geodetic longitude and latitude at which each nominal 
1 km IFOV line of sight intersects the Earth ellipsoid.*. 


pixeLgeodetic_coordinates (data flow) = 

♦Geodetic longitude, latitude and ellipsoid height for each 
nominal 1 km IFOV in a Level 1A data set.*. 


pixel Jook_angles (data flow) = 

♦Solar zenith angle, solar azimuth, satellite zenith angle, 
satellite azimuth, and satellite range for each spatial 
element in a Level 1A data set.*. 
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processing_status (store) = 

*not-def ined* . 


sensor_data_quality (data flow) = 

*not-def ined* . 


start_L1A_processing (control flow) = 

*not-def ined* . 


status_to_PGS (data flow) = 

LlA_status_to_PGS + 

LlB_status__to_PGS + 
higher_level_status_to_PGS . 

♦consists of all status information sent to the PGS toolkit* 
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Appendix C 

MODIS Level 0 and Level 1A Data Rate and Volumes With the Proposed Computerized 

Data Structures 


C-i 




Appendix C 


MODIS Data Rates, Volumes, 
and Processing Performance 
with the proposed 
Computerized Data Structures 


This is document is an evolving master list of thg MODIS data rates and volumes expected from 
the MODIS instrument. Several assumptions have been made in order to provide these estimates 
and these are noted at the point the estimate is presented. An indication of the variance of these 
estimates is included as notes within each section. See the glossary at the end of this document for 
the definitions of MODIS instrument related item descriptions 

The Data Products will be archived in the Hierarchical Data Format (HDF ) which will require an 
agreed upon list of formal names for all parameters and dimension indices. These formal names 
will be presented in a spreadsheet format in future editions of this document, or as separate 
documents for each Data Product. 

Assumed, currently accepted constants 

■ Scan Period: 1.47717 sec/scan (not the mirror rate) (SBRC 9/92) 

■ Orbital Period: 98.9 minutes = 5934 seconds (EOS-AM) 

■ 2 - 250 meter bands 

■ 5 - 500 meter bands 

■ 29-1 kilometer bands 

■ 2 - alternate gain channels (for bands 13 + 14) - These results give (2*16+5*4+29+2=83) 
channels of science data per 1 km spatial element 

■ 10 detectors (for the 1km bands, 20 for 500m bands, 40 for 250m bands) in the along track 
direction form a frame of data (simultaneous readout) 

■ 1354 science frames per scan (705 km satellite altitude, ± 55° scan angle) 

■ 50 solar diffuser (SD) frames per scan 

■ 5 spectroradiometric calibrator (SRC A) frames per frame 

■ 30 black body (BB) frames per frame 

■ 1 5 space view frames per frame 
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■ 2 engineering data frame equivalents (1 engineering and 1 memory dump) - These results give 
50+5+30+15+1354+2=1456 data frames per scan (SBRC 3/93) 

■ 12 bits per pixel for all science, SD, SRC A, BB, and space view detector readout data (SBRC 
3/93) 

■ 14,956,032 bits per day mode scan (SBRC 9/92) - This number includes all science, 
calibration, engineering, and CCSDS header/trailer bits 

■ 2,733,170 bits per night mode scan (SBRC 9/92) 

■ day/night mode mix = 50% day, 50% night (60% day, 40% night would be a 60% duty cycle). 
(Day mode includes all 36 bands, night mode is limited to bands 20 through 36.) 

MODIS Scan Frame and Telemetry Packet Sizes (day and night mode): 

■ 4980 data bits per frame segment (one segment per packet), two segments per day mode frame 
(83 channels * 10 detectors along track * 12 bits per detector / 2 segments per frame) 

■ 2040 data bits per night mode frame (17 channels * 10 detectors * 12 bits per detector), 
unsegmented packets 

■ 108 bits for secondary header and check sum 

■ 48 bits for CCSDS header 

■ 5136 day mode bits or 2196 night mode bits per CCSDS packet 

Derived Packet Transfer Rates: 

■ 14,956,032 bits per day mode scan (2 day mode packets per frame * 1456 frames per scan * 
5136 bits per packet) 

■ 4,021,128 bits per night mode scan (1 packet per frame * 1354 frames per scan * 2196 bits per 
packet + 2 packets per framer * 102 frames per scan * 5136 bits per packet) 

■ 10. 124787 megabits per second, day mode (14,956,032 bits per scan / 1 .47717 scans per 
second) 

■ 2.722183 megabits per second, night mode (4,021,128 bits per scan / 1.47717 scans per 
second) 

Basic Derived Scan Cube Results (day and night mode): 

■ 4017.14 scans per orbit (98.9 minutes per orbit * 60 seconds per minute / 1.47717 scans per 
second) 

■ 14.56 orbits per day (24 hours per day * 60 minutes per hour / 98.9 minutes per orbit) 

■ 58,490.22 scans per day (24 hours per day * 60 minutes per hour * 60 seconds per minute / 
1.47717 scans per orbit) 
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Level-0 Data Volume and Rates: MODIS will be in one of two major modes: day or night. (A 
mode which schedules solar diffuser data deletion is mentioned in the references. This may affect 
the number of data frames in a scan cube) 

■ 1456 data frames per scan * 2 long (5136 bits) packets per frame = 2912 packets per scan (day 
mode) 

■ 1456 data frames * 1 short (2196 bits) packet per frame = 1456 packets per scan (night mode) 

■ 1354 data frames * 1 short (2196 bits) packet per frame plus 102 (full) frames (times 2 packet 
segments per frame) = 1550 packets per scan (night mode). All bands (long segmented 
packets) for non-science data at night is an assumption. 

■ for a 50/50 day/night orbital mix, 2912 packets/scan, day mode * 5136 bits/packet + 204 long 
packets/scan * 5136 bits/packet + 1354 short packets/scan * 2196 bits/packet) * 4017 
scans/orbit / 2 (50/50% mix) / 8 bits/byte = 4.76445 gigabytes per orbit 
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■ for 14.56 orbits per day = 69.37 gigabytes per dav. assuming the night mode non-science 
frames are of the long packet type. This does not include any EDOS accounting information. 

■ 7.5 101 e9 bytes per orbit = 7.5 1 gigabytes per orbit, 100% day rate 

■ 1.0935el 1 bytes per day = 109.35 gigabytes per day, 100% day rate 

■ 1 3724e9 bytes per orbit =1.37 gigabytes per orbit, 100% night rate, assuming the non-science 
frames are of short type 

■ 1.9983el0 bytes per day = 19.98 gigabytes per day, 100% night rate (short non-science 
frames) 

■ 64.67 gigabytes per day, 50/50% day/night mix (if the short non-science night mode frames are 
constrained to 17 data channels) 

■ Level-0 ancillary (accounting, metadata) are to be determined (TBD) and supplied by the 
EDOS design team. 

These data estimates can be considered to be fully accurate with essentially no variance, assuming 
that all frames of data are continuously sampled. It is assumed that the solar diffuser (SD) frame 
data will be enabled for all orbits or the major part of a selected orbit and will be a normal 
component of the scan cube. If the SD data is scheduled to be deleted from the scan data, the data 
rate will reduce by 3.4% (50 divided by 1456 frames) of the full data rate by disabling the SD 
frame data. This may occur for a small fraction of an orbit at a TBD interval (monthly perhaps). 
Other data frames are assumed to be always present (not selectively scheduled). 

Structure of the Level-0 Data Product 

The structure of the Level-0 Data Product and the Level-0 accounting (metadata) product will be 
determined by the MODIS instrument builder (Hughes SBRC) and EDOS respectively. The sizing 
information within this document is based on the best available information available to the 
MODIS SDST at the time this document is updated. 

Level-IA Data description: 

The Level- 1 A data Product Generator is expected to produce two data products: the Level- 1 A 
Data Product and the Level- 1 A Metadata. These products will be produced for both standard and 
quick look data transmission modes. The Level-1 A Data Product consists of three components: 
the science data (ground looking), the calibration data (solar diffuser, black body, space view 
port, etc ), and the engineering data (housekeeping, memory dumps). Data volumes are presented 
as scan cube estimates with orbital and daily volumes summarized at the end of this section. A 
visualization of a scan cube is conceptualized in Figure 1 . 
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An important concept: Science data are obtained from 36 frequency bands, but is organized 
into 83 data channels as follows: One kilometer spatial views are designated as spatial elements 
and consist of 16 - 250 meter IFOVs for each of bands 1 and 2, 4 - 500 meter IFOVs for each of 
bands 3 through 7, and 1 - 1 kilometer IFOV for each of bands 8 through 36. Bands 13 and 14 
have two data channel values (high/low gains at separate detectors) per band. This results in 83 
data channels per 1 km spatial view. Data is assumed to be taken for all channels during the 
calibration phase even if the data is inapplicable (for example: solar diffuser data during MODIS 
night mode). 

A frame of data consists of the above mentioned 83 data channels multiplied by the 10 (or 20 or 
40) along track detectors. Visualizing the scan cube as a loaf of store bought bread, a frame of 
data would be equivalent to a slice of bread, and a loaf would contain 1456 slices. This loaf of 
bread would be flying through space sideways (laterally), which is also how the MODIS 
instrument will travel in orbit (see Figure 2). 

Science Data - day mode 

■ 12 bits per science data value (pixel) unpacked and byte aligned into 2 byte (16 bit) words. 
This is the current assumption for the Level-1 A Data Product. 

■ 2*16 + 5*4 + 29 + (2 dual gain) = 83 data channels (EFOV data values) per spatial element 

■ 10 along track spatial elements per frame 

■ 1354 across track frames per swath (half mirror rotation, one scan) 

■ 1,123,820 day mode science data values per scan cube. (83 channels * 10 spatial elements per 
frame * 1354 frames per scan) 

Science Data : night mode 

■ 12 bits per science data value (pixel) unpacked and byte aligned into 2 byte (16 bit) words 
(assumed) 

■ 17 bands (EFOV data values) per spatial element (bands 20 through 36) 

■ 10 along track spatial elements per frame 

■ 1354 across track frames per swath 

■ 230,180 night mode science data values per scan cube (17 channels * 10 spatial elements per 
frame * 1354 frames per scan) 

Calibration Data - solar diffuser ESDI 

■ 83 channels per 1 km spatial element 

■ 50 frames of data values 

■ 10 elements per frame 
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■ 41,500 solar diffuser data values per scan cube ( = 83 * 50 * 10) (when scheduled) 

Calibration Data - spectroradiometric calibrator (SRCA) 

■ 83 data channels per 1km spatial element 

■ 5 frames of data values 

■ 10 elements per frame 

■ 4150 SRCA data values per scan cube 

Calibration Data - black body (BB) 

■ 83 bands per element 

■ 30 frames of data values 

■ 10 elements per frame 

■ 24,900 black body data values per scan cube ( = 83 * 30 * 10) 

Calibration Data - space view 

■ 83 bands per element 

■ 15 frames of data values 

■ 10 elements per frame 

■ 12,450 space view data values per scan cube ( = 83 * 15 * 10) 

Engineering & Memory Dump Data 

■ low rate housekeeping data (This is a guess based on data available in 1991) 

69 Boolean values 
48 analog values 

■ spacecraft ancillary data (?). Note that the original concept for obtaining the spacecraft 
position and attitude information assumed that this information would be contained within a 
separate packet stream, not a part of the MODIS data. However, the spacecraft will have the 
TONS system onboard which will provide this data on the spacecraft data bus. Detailed 
specifications (values and first derivatives) and data update rates are TBD. 

The engineering data that is listed in the following items is currently assumed to be sampled at the 
MOIDS 12 bit precision. These values will be used to measure the references to be used in the 
calibration techniques. A case can be made to improve the precision of these measurements 
(possible to 16 bits) because the precision of the measuring device should be greater that the 
precision of the item under measurement. 

■ raw black body temperature data 
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12 sensors with 12 (or more) bits per sensor 

■ solar diffuser stability monitor (SDSM) sensor data (?). The spectral emissions of the solar 
diffuser plate. 

■ SRCA self calibrate and reference diode data (?) 

■ scan mirror linearity time data (?). Perhaps a time based encoder readout of the mirror position 
at selected scan frame clock times? 

■ status information (?). Will this include a repeat back of the MODIS Commands and/or 
instrument states? 

■ DC restore offset data (?). Assumed to be for each data channel! What about the data channels 
that have more than one detector? 

■ memory used for functional control (?) 

■ format processor memory as scheduled (?). A computer memory dump. 

■ test and control processor memory as scheduled (?). A computer memory dump. 

■ Engineering & memory Summary - (not representative of the final values) (Any 
decommutation, conversion, or formatting is TBD. Note that the low rate data will be 
submultiplexed and carried in the data set header rather than the scan cubes) 

2 frames * 2 segments per frame * 5 136 bits per segment = 20544 bits per scan 

■ 13540 georeferencing ground locations (one for each spatial element of 1354 frames * 10 
elements per frame) 

Level-IA Data volume and rates: 

■ 1456 frames per scan cube 

■ 83 channels (data values) per spatial element for day mode, 17 channels for night mode 

■ 10 spatial elements per frame 

■ 2 bytes per data value 

■ These result in 2,416,960 bytes of instrument data values per scan cube for day mode (1456 
frames per scan * 83 data channels * 10 detectors along track * 2 bytes per data value) 

■ 629,680 bytes of instrument data values for night mode (1354 frames per scan * 17 data 
channels * 10 detectors along track * 2 bytes per data value + 102 frames * 83 data channels * 
10 detectors along track * 2 bytes per data value) 

■ 8 georeferencing data values (real, floating point numbers) per spatial element, (geodetic 
latitude, longitude and height; solar zenith and azimuth angles; and instrument zenith and 
azimuth angles and slant range). This adds 433,280 bytes to both the day mode and the night 
scan cubes (13540 spatial elements* 8 data values * 4 bytes per data value). 

■ 13540 bytes for data quality (13540 spatial elements * 8 bits per element) 
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Possible decommutation and formatting of engineering data and reformatting of the SRC A data 
and the addition of an 8 bit index into the data quality array may increase these scan cube sizes. 

The total computed summary for the scan cube sizes are : 2,863,780 bytes for day mode and 
1,076,500 bytes for night mode. Note that the spatial element georeferencing consumes 15.1 
percent of the day mode scan cube and 40.2 percent of the night mode scan cube. 

■ 4017. 14 scans per orbit gives a 100% day mode orbital data set size of 1 1 .5042 gigabytes, 
including the header information, and 4.3245 gigabytes for night mode. 

■ For a 50/50 day/night split, (1 1 .5042 + 4.3245) * 50%, 7.916 gigabytes per orbital data set. 
50/50% dav/night split . 

■ 14.56 orbits per day will produce 167.5 gigabytes of Level-IA Data Product per day for 100% 
day mode, 64.964 gigabytes per day for 100% night mode, 115.233 gigabytes per dav for a 
50/50% dav/night split 

These data sizes can be considered to be accurate to ± 3 percent. They include all detector, data 
quality, and georeferencing data but do not include the demultiplexing of any engineering, house 
keeping, or memory damp data. 

Note that data compression is not a consideration at the present time. If data compression will be 
employed, then a fixed length scan cube for both day and night mode would simplify the logical 
organization of the data structure by allowing bands 1 to 19 to be included in the night mode scan 
cube without a storage penalty. 

Structure of the Level-IA Data Product 

The Level-IA Data Product will be generated as two data sets: the Metadata and the Data 
Product. The Metadata will consist of the Level-0 accounting data (an early type of metadata) 
with any MODIS Level- 1 A derived information appended. This value added data is expected to 
be a synopsis of the Data Product, indications of the completeness and quality of the data, and any 
outside user comments on the data. Any structure for this metadata will be determined by the 
EOS project, CCSDS recommendations, and Science Team member input. 

The Level- 1 A Data Product will consist of a header and multiple occurrences of the scan cubes. 
The header information will contain free field (ASCII) information, completeness and quality 
information in both ASCII and binary forms, instrument anomalies, spatial coverage, geolocation 
parametric data, memory dump data, and all other data set related information. The quality 
information in the header will apply to the complete collection of scan cubes. Detailed quality 
about an individual scan cube will be included with each scan cube and summarized in the header. 
Header information (other than the geolocation parametric data) is repeated in the metadata. 
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Each scan cube, as illustrated in Figure 1 , will contain all the data obtained from the instrument 
frames, segmented spacecraft time (MODIS and platform) at each frame, mirror side, source 
identification, and configuration indications. This will apply to the solar diffuser, 
spectroradiometric calibration array, black body, space view, and science view (Earth) data 
portions of the scan. Adjacent to the science data portion of the cube will be the Earth 
georeferencing location and geometry array for each spatial element and a data quality array for 
each spatial element. Following the scan cube will be the Engineering Frames (data 
representations, decommutations, and formatting are TBD), and a detector quality, two 
dimensional array for each data channel (83 channels by 10 along track 1 km spatial elements). 


MODIS Viewing Geometry 
Day Mode / Single Scan 



Figure 2 
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Figure 3 - Pixel Numbering Scheme 

Most of the data processing to be performed in the following Level-2 processes will be performed 
on a pixel by pixel basis. This suggests that the internal scan cube structure should be stored with 
all bands of data for one spatial element in adjacent memory locations. Unfortunately, this could 
only be accomplished with a complicated variable length indexed data structure which could not 
be implemented or accessed in FORTRAN. Also, computer systems that are currently available 
and will be enhanced in the future, can handle the direct addressing of three megabyte arrays with 
no penalties. Plus, the data quality array further complicates any direct easy access to the data 
structure. Therefore, the internal data structure will be principally based on the concept of the 1 
km spatial element with 83 channels of data, in place of a logical 36 band based structure. Data 
can be accessed by a band and IFOV location which will be translated into the internal channel 
and spatial element location via included translation tables. This allows the science data to be 
accessed via the logical spatial index while the internal data cube representation retains the square 
indices. 

The data set will be placed into the HDF representation which is in the process of being upgraded 
for use by the NASA DAACS. Facilities within the HDF technique in the future may allow for 
indexing, that could simplify the data structure as presented here. The VSET capability in HDF 
will allow the georeferencing to be applied to the Level 1A, IB, and 2 data sets concurrently 
without a storage penality. Georeferencing can be extracted and appended to distributed data sets 
as needed. 

The major components of the Level- 1 A output Data Product structure with descriptors are listed 
in the following item list. 

MODIS Level 1 A Data Product Header 

■ Source of the data set 

■ spatial extent -coverage at nadir and selected latitudes 

■ temporal extent - date, time, and ephemeris 

■ georeferencing parameters - a set of coefficients that will allow the data set to be geolocated to 
less accuracy than the georeferenced spatial element points. The SDST will supply a software 
function that will allow MODIS data product users to determine the ground location, given 
these parameters. 
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■ pointers to all related data sets - metadata, calibration measurements, DEM, etc 

MQDIS Level 1A Data Product Scan Cubes 

■ Raw Science Data - three dimensional array - along track, across track (= scanwise), band 
number 

■ Raw Solar Diffuser Data - three dimensional array - along track, scanwise, band number 

■ SRCA Data - three dimensional array - along track, scanwise, band number 

■ Raw Black Body Data - three dimensional array - along track, scanwise, band number 

■ Raw Space View Data - three dimensional array - along track, scanwise, band number 

■ Band Number to Data Channel translation tables - three tables that translate the logical along 
track index, the logical across track index, and the band number into the three dimensional 
cube data channel array indices. Note that the logical cube indices have differing ranges as a 
function of the band number. 

■ Spatial Data Quality - two dimensions - along track, across track at 1 km indices. Eight bits 
will allow 255 possible quality specifications to be determined on a per spatial element basis. 

■ Time Tag - array with two tags per frame for day mode, one tag for night mode. This will be 
subdivided into the various time elements when they have been further specified by EOS and 
SBRC. 

■ Geolocation - a set of real (floating point) values that specify the latitude, longitude, solar 
zenith, solar azimuth, instrument zentith, instrument azimuth, and instrument range for each 
lkm spatial element. These are not the parametric coefficients included in the data set header 
that are used for less accurate geolocation. 

■ SDSM - The view direction and integrating sphere data readouts. 

■ Engineering / Memory Dumps - these are a set of sequential variables or linear arrays, the 
format and contents of which are (TBD). Note that the memory dumps and many engineering 
readings are sampled at a much lower rate that the scan cube rate. These data will be 
submultiplexed within this data area. 

■ Band Quality - array - the data quality specified for all IFOVs combined, one index per data 
channel. 


A parametric software routine giving the ground location of any science data value will be 
provided as part of the Data Product header data structure specifications. An array of data quality 
descriptors in ASCII form, given the data quality index number, will also be included in the scan 
cube specification. These items will be derived at a future date. 

Bands 13 and 14 have both a high gain and a low gain data channel, corresponding to the two 
detectors for each of these bands. For the purposes of the Level 1 A Data Product, which contains 
the raw instrument counts, the high gain channels will be accessed as logical bands 37 and 38. 
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Coordinate System 


The scan cube coordinate system, illustrated in figure 2 and further defined in figure 3, follows the 
SBRC detector numbering scheme with 40 detectors for bands 1 and 2, 20 detectors for bands 3 
to 7, and 10 detectors for the remaining bands in the along track direction and 5416, 2708, and 
1354 frames of detector readouts, respectively, in the across track (along scan) direction. This 
coordinate system will follow through (using the same scheme) for the solar diffuser, SRCA, 
black body, and space view data. 

The illustration in figure 2 shows a view of the Earth, looking from the Sun, during a day mode, 
descending orbital pass. The EOS-AM orbit plane will be inclined 8 degrees from vertical as 
shown. This corresponds to an orbital inclination of 98 degrees. The satellite will pass over the 
equator at 10:30 am local time. This corresponds to a 22.5 degree rotation about the Earth 
vertical axis in the westerly direction. A scan cube at the equator during the day mode, will be 
'tilted' 8 degrees clockwise as viewed from above. The MODIS instrument will scan from left to 
right, and generate successive scan cubes from top (north) to bottom (south). The nightime pass 
will 'tilt' 8 degrees at the equator in the counterclockwise direction, create scan cubes south to 
north and scan right to left as viewed from a point opposite the Sun. 


The current pixel numbering scheme uses increasing numbers in the scan direction, but decreasing 
numbers in the along track dimension. Numbers in parentheses in the included diagram represent 
the limits of the pixel numbering for the 500 meter and 250 meter bands respectively. Pixel 
numbering for the solar diffuser, black body, and space view will follow the same along track 
system but will have across track limits to match the number of data frames. 


Level 1A Profiling and Computing Resources 
Input / Output Rates 


Note that any data staging by the DADS or other facilities in the data transmission chain are not 
included in this discussion. 

■ One long packet of 5 136 bits = 642 bytes, short packet of 2196 bits = 275 bytes. 

■ 2912 packets per day mode scan, 1354 short and 102 long packets per night mode scan, 
4017. 14 scans per orbit, and an orbital period of 98.9 minutes give an input channel rate of 
1510.32 packets per second orbital average. 

■ The maximum input packet size (day mode) gives a real time maximum Level-0 input rate of 
.9696 megabytes per second. 

* A day mode scan cube size of 2.9 megabytes every 1.47717 seconds gives a maximum Level 
1A output rate of 1.963 megabytes per second. 
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■ A night mode scan cube size of 1 . 1 megabytes every 1 .47747 seconds gives a maximum Level 
1A output rate of .75 megabytes per second. 

Processing Power 

The following numbers represent a best guess and do not represent any detailed dasign or 
prototyping efforts at the present time. 

■ Incoming packet validation - (2 mips estimated) 

■ Placement of instrument data from packets into scan cubes - 1.208 million detector values 
(1456*10*83) per scan cube with <20 operations (2 loads, 1 store, 1 and, 12 shifts, 1 or) = 
24,160,000 operations per scan cube 

■ Georeferencing for each of the 13540 spatial elements (from the "MODIS Level 1 A 
Geolocation Processing Estimate" internal document. A total of 41.4 mflops, with the 
following breakdown: 

■ geolocation to the ellipsiodal Earth - 1,519,188 operations per scan cube (657 multiplies, 
373 adds, 70 trigometric, and 22 square roots per frame * 1354 frames per scan cube) 

■ Digital Terrain Model (DTM) correction - 1,632,924 operations per scan cube (686 
multiplies, 438 adds, 56 trigometric, and 26 square roots per spatial element * 1354 frames 
per scan cube * 10 spatial elements per frame) 

■ ancillary angle (zenith and azimuth) determination - 1,221,308 operations per scan cube 
(512 multiplies, 268 adds, 82 trigometric, and 40 square roots per frame * 1354 frames per 
scan cube) 

■ Allowing for data quality testing, message passing, possible packet ordering, engineering data 
organization and validation, etc. an initial guess of ~20 mips multiplied by suitable scaling 
factor (TBD) would be appropriate. 

■ Scan cube handling overhead - 1 mips estimated. 

■ TOTAL Processing Power (assuming mips = flops) = 88.5 mflops, minimum. 

These results can be considered accurate for the I/O (input/output) rates, but highly speculative 
for the processing power estimates. Note that the I/O rates use relatively small data transfer sizes, 
resulting in a high I/O channel overhead. Blocking these packets into larger entities would 
produce a more efficient system from an I/O view point. 

Important notei Possible future requirements that need to be kept in mind for the level 1 A 
processing may include the determination of a land / water / cloud mask, the separation of ground 
truth data, or a target of opportunity algorithm such as a volcanology algorithm with location 
information to be passed to the ASTER team for rapid pointing to targets of opportunity. 
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GLOSSARY 


■ Pixel -The smallest decomposed unique science data value. One pixel represents the data 
from one spatial position and one channel of data. 

■ Anchor Point Array - a spatial array of Earth located positional values (latitude, longitude, 
and possibly elevation) that determines the location of a selected subset of the science data 
pixels. 

■ Spatial Element - all channels of data corresponding to a 1 kilometer ground equivalent field 
of view. This means that 16 - 250 meter detectors, 4 -500 meter detectors, and 1 - 1 km 
detector reside within one spatial element. 

■ Channel - the data derived from an instrument data gathering electronic channel. Channels 
of data may be obtained in parallel. Contrast this with a band of data. 

• Band - A center frequency and filter function width combination that are referenced by an 
arbitrary number. One channel usually measures data from one band, but MODIS has two 
channels of data for each of bands 13 and 14. 

■ Scan Cube - The three dimensions of the science data: along track, across track, and band 
number with ground locations, engineering data (per scan), and quality indications attached. 

■ Frame - A set of data representing one instance of: all bands of science data and 10 along 
track spatial elements (day or night mode), or all bands & 10 spatial elements of solar 
diffuser, black body, or space view data, or specialized data from the SRCA or Engineering 
/ Memory dumps. 

■ Swath - Engineering term for a half mirror rotation. This is equivalent to a scan cube. 

■ Metadata - Information describing the content, format, and utility of a data set. 
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